Add Sentry adapter with four read-only tools - #551
Conversation
|
👋 Welcome, @Nagharjun17, and thanks for opening your first PR on AnythingMCP! A few quick pointers:
Someone from the core team will look at this within ~48h. If you don't hear back, please ping us in Discussions / Q&A. ⭐ While you wait — if you find AnythingMCP useful, a star helps others discover it. |
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
keysersoft
left a comment
There was a problem hiding this comment.
Hi Nagharjun, thanks for this. I went through the JSON and the live spec and it's a solid first adapter: the descriptions actually tell the model when to use which tool, the params are explicit with examples, and you were upfront about the pagination limit instead of hiding it. Also nice that you found the regenerate script on your own, the issue text was out of date on that (fixed now).
Two things before I merge, the first one matters, the second is optional.
-
The organization slug. Right now every tool requires
organization_id_or_slug, so the model has to know it or ask on every call. We handle this kind of thing with an env var. AddSENTRY_ORGtorequiredEnvVars, write the paths as/organizations/{{SENTRY_ORG}}/issues/and so on, and drop the parameter from the tools. The double braces are resolved from the connector's env vars at call time, the WhatsApp and Amazon Seller adapters do exactly this if you want a reference (intl/whatsapp-business.json). The user sets it once when installing and never thinks about it again. -
Self hosted Sentry. If you make the base URL
{{SENTRY_BASE_URL}}withhttps://sentry.io/api/0as the default in the env var description, the same adapter works for people running their own Sentry. Those are honestly the users most likely to pick AnythingMCP over the official Sentry connector, so it's worth the one line. Totally fine to leave it for a follow up if you prefer.
On pagination: that's a limitation of our REST engine (it only hands the body back to the tool, never the response headers), not something you should work around here. I opened #557 for it. Leave the cursor param as you have it.
Guide page, logo and the marketplace listing are on our side after the merge, you don't need to do anything for those.
|
Quick update on the pagination point. The engine limitation is gone: #557 landed today and is live in 0.7.0. A REST tool can now ask for response headers, so your two list tools can work through all pages instead of one. The change on your side is small. On "exposeHeaders": ["link", "x-sentry-rate-limit-remaining"]to the Together with the |
|
Nudge on this one, no pressure. The adapter itself is ready and the checks are green now that I approved the fork workflows. What is still open from my review is the |
Finishing @Nagharjun17's adapter so it can go in. Their tools, descriptions and live spec; these are the three changes from the review. - SENTRY_ORG becomes an env var and goes into every path as {{SENTRY_ORG}}, so the model no longer has to know the organization slug on each call and cannot get it wrong. The parameter is gone from all four tools. - The three list tools opt into exposeHeaders, which HelpCode-ai#558 made possible after this PR was opened. Sentry paginates with a Link header, so each response now carries _pagination and the cursor descriptions say to follow nextCursor until it disappears. Before this, every list tool was exactly one page long, which the instructions had to apologise for. - The quoted adapter count moves 190 to 191 in the seven files the CI gate checks, which a new adapter always has to do. The base URL stays sentry.io rather than becoming {{SENTRY_BASE_URL}} as I first suggested: an optional placeholder that nobody fills in would be sent to the vendor as the literal string, which is a failure mode we hit elsewhere today. Self-hosters edit the connector's base URL after installing, and the instructions now say so. The live spec substitutes {{SENTRY_ORG}} itself, since it drives the engine directly and interpolation happens a layer above.
|
Merged. Thank you for this, and sorry it sat for a few days. Rather than keep you waiting on the two review points, I did them on your branch so the adapter goes in with your name on it. What I changed, and why: The organization is an env var now. Pagination actually works. The three list tools opt into Counts. A new adapter has to bump the quoted number in the seven files the CI gate checks, 190 to 191. Easy to miss, nothing to do with your work. One place I went against my own earlier suggestion: I left the base URL as Your live spec now substitutes Guide page, logo and marketplace listing are on us. If you want a follow-up, write tools are the obvious next step now that the read side is in, and a |
Summary
Add a Sentry adapter so agents can discover projects, investigate issues,
and inspect individual error events with stack traces.
Changes
and list issue events.
Type
Testing
The root npm test command finishes the backend tests but exits with an
error because the frontend workspace has no test script. The backend run
also reported a worker-shutdown warning.
Limitations
List tools return one page. Sentry supplies pagination cursors in Link
headers, but the REST engine returns only the response body. The adapter
accepts externally supplied cursors and documents this limitation.
Related Issues
Relates to #150.